Reduce amount of /transaction calls in MetadataTracker in system without change if /nextTransaction is available #434
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reduces the overhead in polling for new transactions to index when a system is mostly read-only / without changes for a long time. This is something I had already noticed myself in production systems, but came about as a result of a question in the Alfresco forum. In essence, the longer a system is without a change, the more calls the MetadataTracker executes against the /transactions (and /nextTransaction if available) endpoint of the Repository as it looks for any transaction to index.
This PR adds missing logic to stop the loop to incrementally scan the transaction table when the nextTransaction endpoint is available and returns a value indicating that no newer transaction exists at all. It also adjusts the startTime for the next iteration if a next transaction commit time is available but the transactions return in the subsequent call to the transactions endpoint where somehow already "found" before.
A similar issue exists with the ACL tracker. This also executes an increasing amount of calls to look for newer change sets in any system where no ACL changes are performed for a long time. Since there is no endpoint to find the next commit time for an ACL change set based on the last commit time, the overhead there cannot currently be improved in the same way as in the MetadataTracker.